Design verification is a common process for testing a newly designed integrated circuit, board, or system-level architecture, to, for example, confirm that it complies with the requirements defined by the specification of the architecture for that device. Design verification for a device under test (DUT) may be performed on the actual device, but can usually be a simulation model of the device is tested.
Verification of electronic designs may typically have three forms. At an early stage, before the electronic design is implemented in hardware, simulation can be conducted on a model of the design. Another form can be emulation, in which an electronic hardware may be used to mimic the behavior of another (tested) electronic hardware. At more advanced stages of design development, a system on chip may be validated, in a process which is typically referred to as post-silicon validation. Post-silicon validation can be a last stage in the electronic design development, for example, before it is manufactured.
An electronic system (e.g., a smartphone, a tablet, etc.) may typically be made up of a plurality of electronic devices (e.g., memory, camera, central processing unit—CPU, graphical processing unit—GPU, microphone, media player, etc.). At the early stages in the development of electronic design, a model of each of the electronic devices that form the electronic system can be built (typically in Verilog or other HDL language and verified, by simulating executions of a multitude of tests on the on a simulation of the DUT. In order to, for example, efficiently cover all (or substantially all) functionalities of the DUT a plurality of tests can be generated. The plurality of tests can be pieces of code, e.g., C-code, assembly, and/or other codes as are known in the art. Each of the plurality of tests can be generated from one of various scenarios which can be constructed by a one or a plurality of users. Each scenario can be made up of a plurality of actions which the user selects to be included in the scenario. The user may also define the order in which the selected actions are to be performed—consecutively or concurrently.
In a typical verification process an electronic design undergoes test regressions which includes designing various validated testing scenarios that are generated in a test code form and executed.
In the development process of an electronic product numerous tests can be designed and accumulated. In the verification process, the same test may be reused and rerun by selecting and/or later changing one or more of its execution modes and/or execution conditions. For example, running the test per each or any of the designated processor type (32 bits, or 64 bits), running the test per each or any type of compilers (e.g., Linux compilers, for example, GCC, G++, hardware compilers, for example, ARM compiler, simulation compilers, etc.), running the test with or without performing tracing, running the test in each or any of a list of debug levels (e.g., in verbosity levels such as, none, low, high, full), running only tests in which action a and action b are not performed concurrently, running only tests in which action a and action b are performed concurrently, etc. Other configuration modes may also be offered to be considered and selected.
As the number of accumulated tests soar it may become increasingly difficult and/or very inefficient to run all existing tests on a DUT, in all possible combinations of execution conditions and/or modes (hereinafter referred to as “execution parameters”), and it therefore may be desired to reduce the number of test to be run in a test regression, yet maintain efficient and qualitative testing.